Personal computer conferencing allows a computer user to participate in a meeting from his own desk instead of travelling to a location mutually convenient to all parties. Just as telephony systems have developed to include conference calls to more than two parties so have computer systems developed to allow large numbers of networked computer users to participate in a single conference. An example of personal conferencing is an internet `chat room` in which one can conduct meetings in text or voice in real time with other computer users.
A development of the `chat room` type conference is the application type conference in which Personal Conferencing systems try to allow a number of participants to share applications so that they can all interact with them and see the same results. One example of this is the `white board` application in which participants can draw on a `common` white board and see and edit the same drawing. Another example is a molecular modelling application in which each participant may change and manipulate a molecule displayed on the computer screen.
Some Personal Conferencing Systems are implemented in a peer-to-peer fashion. An example of this are the PM2PM and Person to Person/2 products developed by IBM Corporation. In this environment, for example (see FIG. 1) a conference management/call manager program (18A, 18B) runs in each computer (10A, 10B) drawing upon the services of one or more network adaptors (12A, 12B) to communicate over a network (14). A number of specially written personal conferencing applications (16A, 16B, 16C) connect to the conference management. If a conference includes a shared chalkboard, for example, then on each participating node chalkboard personal conferencing applications (16A, 16B, 16C) will be running. These applications send packets of data to each other, utilising the services of the conference management program (18A, 18B).
This arrangement has the following drawbacks:
(i) As the conferencing management program is not responsible for ensuring that the data in the application on each node corresponding to the same shared chalkboard (or other data) is the same, the applications must invent and use a protocol between them for doing so. PA0 (ii) Each node may elect to not store an entirely identical copy of the data which its peers do. This design decision is often made in error, as it tends to expedite a rapid implementation, with the side effects not being immediately apparent. PA0 (iii) If a new participant joins the conference, then a copy of the data in the chalkboard (or other data) must be transmitted from one of the nodes. If the data on each node is not identical, then which data is best sent? For an efficient transfer, the application may need an appreciation of the network geography, further complicating the implementation of the application. When a new participant joins the conference, and wishes to share an existing application he must be brought into step. PA0 (iv) All this extra complication in the applications (peer-to-peer protocol to keep data in step, joining and leaving transfer, knowledge of geography) must be duplicated in each sort of application. PA0 (v) A person may not indicate their readiness to participate in a conference on their own, as there is no `meeting point` inherent in the system. There is no server which can reasonably expect to be powered up at any time, in a purely peer-to-peer system. PA0 (i) Its not a collaborative application `enabler`. PA0 (ii) Non-collaborative applications are written with one user in mind and keystrokes and mouseclicks are from a variety of users, all interleaved in time. PA0 (iii) All users can only see an identical view of the data. eg: User one cannot see a zoomed view of the chalkboard, whilst user two sees the normal size. PA0 (iv) Changes to the application data can result in large quantities of screen changes (and thus X-protocol), and this problem is made worse by the fact that it is now sent to all the participants. PA0 (v) The application is really only running on one machine, and so the data it holds is only accessible on that machine unless all the machines share a common file-system (such as AFS or DFS). Even if machines share access to a common file-system, drive letters and pathnames may be different across machines, for the same file. Generally, when manipulation remote data, you (the user) have to consider that you are running on the remote machine. This is added complexity for the user.
An example of personal conferencing which does not allow manipulation of shared data by either party, is simplified Peer-to-Peer such as the shared whiteboard application in the NeWI environment developed by Data Connection Limited. The whiteboard has multiple planes, one per participant. Each participant can draw upon his own plane, and changes to his plane is transmitted to the other participants, who can then see (but not change) the new plane. As nobody can change the picture on the plane of another, there is no shared manipulation of shared data. `NeWI` is a trademark of Data Connection Limited.
Simplified Peer-to-Peer has further disadvantages. Although in the example of a shared whiteboard some utility is afforded by such a tool, most of the value is in the shared manipulation of data. Although this system is simple to implement, this style of `conferencing` is awkward for text editing and other forms of shared manipulation.
One of the main problems of peer-to-peer conferencing systems is therefore that of serialisation, the requirement that all the data must arrive at all the destinations/nodes in the same order to preserve the conference model integrity. The order used is normally the order in which the data is sent.
A different type of personal conferencing is provided by the XTV system developed by IBM Corporation. This is an enhancement/modification of the XWindows system. If the input events (mouse-clicks, keystrokes etc.) from a variety of participants can be transmitted to a given machine, applied to a running program, and the resulting changes to the screen (or windows of the program) transmitted back to the participants, a rudimentary form of personal conferencing can be achieved.
XWindows is a client-server system, whereby the servers serve the ability to provide user input, and also serve the ability to draw to their screen. Typically each user has an Xserver (20) running on their machine and the data-stream is sent to the Xserver (20) via an XTV interceptor (22) to get it to display graphics using X-protocol. As XWindows is client-server, and X-protocol is transmitted between them, it is usual for clients and servers to be running in different machines. XWindows implies networking, and this is handy when collaborative working is desired (as in personal conferencing). For output, XTV (22) intercepts the X-protocol sent by an application running on a client (24) to a server (26). It fans this data out to a number of Xservers (20), thus making the programs windows visible to a number of participants. Similarly, input is drawn from a number of Xservers (20), and channelled in to the machine running the shared (multiply accessible) application. XTV and XWindows are trademarks of IBM Corporation.
Normal XWindows client-server interaction is shown in FIG. 2A and Interaction with XTV (22) `in the middle` is shown in FIG. 2B. XTV (22) routes input and output traffic between a number of applications and servers and has the advantage of working with all existing non-collaborative applications.
However, it has the following drawbacks:
Another problem of most types of Personal Conference system is that no attempt has been made to optimize the network performance by choosing the nearest (network speed wise) existing participant to the new participant. Commonly, personal conference systems have transmitted the data from an arbitrary existing node to a new node.
EPO497022 Hewlett-Packard relates to a distributed object-based computer system in which sharable objects are split into client and server components. It is designed for a number of servers which communicate amongst themselves to send messages and deliver updates.
The embodiment of the invention draws on a number of disciplines for its performance. One of these Model/View/Controller (or MVC for short) is a discipline used in implementing applications. Such an application is divided up into three logical parts, with clearly defined interfaces and responsibilities.
The Model is the data which the application is presenting and allowing to be manipulated. However the Model itself only contains the data and entrypoints (ie: methods) by which the data may be changed. The Model has no concept of how the data is to be presented to the user, and no concept of how a user indicates or is allowed to specify their intended change/modification of the data. In the example of a Chalkboard application, the Model could be a bitmap representing the picture. The Model would not include any concept of a current pen colour, fill style or font setting etc. Modification of the data in the Model is achieved through the entrypoints/methods, and the new state of the Model is determined entirely from the old state and the parameters to the entrypoint (ie: the entrypoints are pure, and do not use global data). In this description the entrypoints/methods are associated with operating on the data of the model or the `means for operating`.
The View is the user-interface components for showing the user the current state of the Model. It determines how to display the model purely from the Model data it is configured to show, with access to no external or global variables. That is to say that given a particular Model, you will always get the same visual representation. In the example of a Chalkboard application, the View might chose to display the Models bitmap in the client area of a window, with scrollbars.
The Controller is the user-interface components for allowing the user to specify changes to the Model. In the example of a Chalkboard application, the Controller is responsible for showing the rubberbanding which occurs when the user decides to draw a rectangle (or other graphic symbol) on the Chalkboard. The Controller does not directly modify the Model (eg: draw the rectangle)--rather it calls entrypoints in the Model to get this job done. The Controller can maintain the users current choice of pen colour and font, and this information is passed as a part of a draw-rectangle command passed to the Model (in order that the change be completely specified). In this description the controller is associated with the creation of an operating instruction or the means for creating.
In the interests of efficiency, when a Model has changed, it may notify the View (or Views) of itself of the fact that it has changed, and perhaps the extent of the change. This allows the View to redraw itself to reflect the change, or even to selectively redraw the part of itself that has been affected.
In practice the distinction between Controller and View is often blurred. In the case of the Chalkboard, the same client window might both display the current View of the bitmap and the rubberbanding taking place due to the current user interaction with the Controller.
The embodiments of the present invention attempt to address these and other problems.